home *** CD-ROM | disk | FTP | other *** search
/ PCGUIA 127 / PC Guia 127.iso / Software / Utils / TightVNC / Bin / tightvnc-1.3dev7-setup.exe / {app} / Web / doc / java / README.txt
Encoding:
Text File  |  2005-07-06  |  19.0 KB  |  437 lines
  1.  
  2. TightVNC Java Viewer version 1.3dev7
  3. ====================================
  4.  
  5. Copyright (C) 2001-2004 HorizonLive.com, Inc.  All Rights Reserved.
  6. Copyright (C) 2001-2005 Constantin Kaplinsky.  All Rights Reserved.
  7. Copyright (C) 1999 AT&T Laboratories Cambridge.  All Rights Reserved.
  8.  
  9. This software is distributed under the GNU General Public Licence as
  10. published by the Free Software Foundation. See the file LICENCE.TXT for the
  11. conditions under which this software is made available. TightVNC also
  12. contains code from other sources. See the Acknowledgements section below, and
  13. the individual files for details of the conditions under which they are made
  14. available.
  15.  
  16.  
  17. Compiling from the sources
  18. ==========================
  19.  
  20. To compile all the .java files to .class files, simply do:
  21.  
  22.     % make all
  23.  
  24. This will also generate a JAR (Java archive) file containing all the classes. 
  25. Most JVM (Java Virtual Machine) implementations are able to use either a set
  26. of .class files, or the JAR archive.
  27.  
  28.  
  29. Installation
  30. ============
  31.  
  32. There are three basic ways to use TightVNC Java viewer:
  33.  
  34.   1. Running applet as part of TightVNC server installation.
  35.  
  36.      Both the Unix and Windows versions of TightVNC servers include small
  37.      built-in HTTP server which can serve Java viewer to Web clients. This
  38.      enables easy Web access to the shared desktop without need to install
  39.      any software on the client computer. Unix and Windows versions of
  40.      TightVNC servers are different in the way they store the .class and .jar
  41.      files: the Unix server (Xvnc) is able to serve any set of files present
  42.      in a particular directory, while the Windows server (WinVNC) has all the
  43.      .class and .jar files inside the WinVNC executable file. Therefore, for
  44.      Xvnc, it's enough to copy the files into a correct directory, but for
  45.      WinVNC, the server binaries should be rebuild if the built-in Java
  46.      viewer should be updated.
  47.  
  48.      To install the Java viewer under Xvnc, copy all the .class files, the
  49.      .jar file and the .vnc files to an installation directory (e.g.
  50.      /usr/local/vnc/classes):
  51.  
  52.          cp *.class *.jar *.vnc /usr/local/vnc/classes
  53.  
  54.      Also, make sure that the vncserver script is configured to point to the
  55.      installation directory (see the Xvnc manual page for the description of
  56.      the -httpd command-line option).
  57.  
  58.   2. Running applet hosted on a standalone Web server.
  59.  
  60.      Another possibility to use the Java viewer is to install it under a
  61.      fully-functional HTTP server such as Apache or IIS. Obviously, this
  62.      method requires running an HTTP server, and due to the Java security
  63.      restrictions, it's also required that the server should be installed on
  64.      the same machine which is running the TightVNC server. In this case,
  65.      installation is simply copying the .class and .jar files into a
  66.      directory that is under control of the HTTP server. Also, an HTML page
  67.      should be created which will act as a the base document for the viewer
  68.      applet (see an example named index.html in this distribution).
  69.  
  70.      NOTE: Provided index.html page is an example only. Before using that
  71.      file, edit it with a text editor. See more information inside
  72.      index.html.
  73.  
  74.   3. Running the viewer as a standalone application.
  75.  
  76.      Finally, the Java viewer can be executed locally on the client machine,
  77.      but this method requires installation of either JRE (Java Runtime
  78.      Environment) or JDK (Java Development Kit). If all the .class files are
  79.      in the current directory, the Java viewer can be executed like this,
  80.      from the command line:
  81.  
  82.          java VncViewer HOST vnchost PORT 5900
  83.  
  84.      The parameters HOST and PORT are required, but there is a number of
  85.      optional parameters as well (see the Parameters section below).
  86.  
  87. Parameters
  88. ==========
  89.  
  90. TightVNC Java viewer supports a number of parameters allowing you to
  91. customize its behaviour. Most parameter names copy settings available from
  92. the Options frame in the Java viewer. Both parameter names and their values
  93. are case-insensitive, with one exception for the "PASSWORD" parameter. Here
  94. is the full list of parameters supported in TightVNC Java viewer:
  95.  
  96. --> "HOST" (no GUI equivalent)
  97.  
  98.     Value: host name or IP address of the VNC server.
  99.     Default: in applet mode, the host from which the applet was loaded.
  100.  
  101.     This parameter tells the viewer which server to connect to. Normally,
  102.     it's not needed, because default Java security policy allow connections
  103.     from applets to the only one host anyway, and that is the host from which
  104.     the applet was loaded.
  105.  
  106. --> "PORT" (no GUI equivalent)
  107.  
  108.     Value: TCP port number on the VNC server.
  109.     Default: none.
  110.  
  111.     This parameter is required in all cases. Note that this port is not the
  112.     one used for HTTP connection from the browser, it is the port used for
  113.     RFB connection. Usually, VNC servers use ports 58xx for HTTP connections,
  114.     and ports 59xx for RFB connections. Thus, most likely, this parameter
  115.     should be set to something like 5900, 5901 etc.
  116.  
  117. --> "PASSWORD"
  118.  
  119.     Value: session password in plain text.
  120.     Default: none, ask user.
  121.  
  122.     DO NOT EVER USE THIS PARAMETER, unless you really know what you are
  123.     doing. It's extremely dangerous from the security point of view. When
  124.     this parameter is set, the viewer won't ever ask for a password.
  125.  
  126. --> "ENCPASSWORD"
  127.  
  128.     Value: encrypted session password in hex-ascii.
  129.     Default: none, ask user.
  130.  
  131.     The same as the "PASSWORD" parameter but DES-encrypted using a fixed key.
  132.     Its value should be represented in hex-ascii e.g. "494015f9a35e8b22".
  133.     This parameter has higher priority over the "PASSWORD" parameter. DO NOT
  134.     EVER USE THIS PARAMETER, unless you really know what you are doing. It's
  135.     extremely dangerous from the security point of view, and encryption does
  136.     not actually help here since the decryption key is always known.
  137.  
  138. --> "Encoding"
  139.  
  140.     Values: "Raw", "RRE", "CoRRE", "Hextile", "Zlib", "Tight".
  141.     Default: "Tight".
  142.  
  143.     The preferred encoding. "Hextile" is a good choice for fast networks,
  144.     while "Tight" is better suited for low-bandwidth connections. From the
  145.     other side, the "Tight" decoder in TightVNC Java viewer seems to be more
  146.     efficient than "Hextile" decoder so it's possible that this default
  147.     setting can be ok for fast networks too.
  148.  
  149. --> "Compression level"
  150.  
  151.     Values: "Default", "1", "2", "3", "4", "5", "6", "7", "8", "9".
  152.     Default: "Default". ;-)
  153.  
  154.     Use specified compression level for "Tight" and "Zlib" encodings. Level 1
  155.     uses minimum of CPU time on the server but achieves weak compression
  156.     ratios. Level 9 offers best compression but may be slow in terms of CPU
  157.     time consumption on the server side. Use high levels with very slow
  158.     network connections, and low levels when working over higher-speed
  159.     networks. The "Default" value means that the server's default compression
  160.     level should be used.
  161.  
  162. --> "JPEG image quality"
  163.  
  164.     Values: "JPEG off", "0", "1", "2", "3", "4", "5", "6", "7", "8", "9".
  165.     Default: "6".
  166.  
  167.     Use the specified image quality level in "Tight" encoding. Quality level
  168.     0 denotes bad image quality but very impressive compression ratios, while
  169.     level 9 offers very good image quality at lower compression ratios. If
  170.     the value is "JPEG off", the server will not use lossy JPEG compression
  171.     in "Tight" encoding.
  172.  
  173. --> "Cursor shape updates"
  174.  
  175.     Values: "Enable", "Ignore", "Disable".
  176.     Default: "Enable".
  177.  
  178.     Cursor shape updates is a protocol extension used to handle remote cursor
  179.     movements locally on the client side, saving bandwidth and eliminating
  180.     delays in mouse pointer movement. Note that current implementation of
  181.     cursor shape updates does not allow a client to track mouse cursor
  182.     position at the server side. This means that clients would not see mouse
  183.     cursor movements if mouse was moved either locally on the server, or by
  184.     another remote VNC client. Set this parameter to "Disable" if you always
  185.     want to see real cursor position on the remote side. Setting this option
  186.     to "Ignore" is similar to "Enable" but the remote cursor will not be
  187.     visible at all. This can be a reasonable setting if you don't care about
  188.     cursor shape and don't want to see two mouse cursors, one above another.
  189.  
  190. --> "Use CopyRect"
  191.  
  192.     Values: "Yes", "No".
  193.     Default: "Yes".
  194.  
  195.     The "CopyRect" encoding saves bandwidth and drawing time when parts of
  196.     the remote screen are moving around. Most likely, you don't want to
  197.     change this setting.
  198.  
  199. --> "Restricted colors"
  200.  
  201.     Values: "Yes", "No".
  202.     Default: "No".
  203.  
  204.     If set to "No", then 24-bit color format is used to represent pixel data. 
  205.     If set to "Yes", then only 8 bits are used to represent each pixel. 8-bit
  206.     color format can save bandwidth, but colors may look very inaccurate.
  207.  
  208. --> "Mouse buttons 2 and 3"
  209.  
  210.     Values: "Normal", "Reversed".
  211.     Default: "Normal".
  212.  
  213.     If set to "Reversed", then right mouse button (button 2) will act as it
  214.     was middle mouse button (button 3), and vice versa.
  215.  
  216. --> "View only"
  217.  
  218.     Values: "Yes", "No".
  219.     Default: "No".
  220.  
  221.     If set to "Yes", then all keyboard and mouse events in the desktop window
  222.     will be silently ignored and will not be passed to the remote side.
  223.  
  224. --> "Scale remote cursor"
  225.  
  226.     Values: "No", "50%", "75%", "125%", "150%".
  227.     Default: "No".
  228.  
  229.     If a percentage value is specified, the remote cursor is reduced
  230.     or enlarged accordingly. Scaling takes place only when "View only"
  231.     is set to "No", and "Cursor shape updates" is set to "Enable".
  232.  
  233. --> "Share desktop"
  234.  
  235.     Values: "Yes", "No".
  236.     Default: "Yes".
  237.  
  238.     Share the connection with other clients on the same VNC server. The exact
  239.     behaviour in each case depends on the server configuration.
  240.  
  241. --> "Open new window" (no GUI equivalent, applicable only in the applet mode)
  242.  
  243.     Values: "Yes", "No".
  244.     Default: "No".
  245.  
  246.     Operate in a separate window. This makes possible resizing the desktop,
  247.     and adds scroll bars when necessary. If the server supports variable
  248.     desktop size, the window will resize automatically when remote desktop
  249.     size changes.
  250.  
  251. --> "Show controls" (no GUI equivalent)
  252.  
  253.     Values: "Yes", "No".
  254.     Default: "Yes".
  255.  
  256.     Set to "No" if you want to get rid of that button panel at the top.
  257.  
  258. --> "Offer relogin" (no GUI equivalent, not applicable in the applet mode)
  259.  
  260.     Values: "Yes", "No".
  261.     Default: "Yes".
  262.  
  263.     If set to "No", the buttons "Login again" and "Close window" won't be
  264.     shown on disconnects or after an error has occured.
  265.  
  266. --> "Show offline desktop" (no GUI equivalent)
  267.  
  268.     Values: "Yes", "No".
  269.     Default: "No".
  270.  
  271.     If set to "Yes", the viewer would continue to display desktop even
  272.     if the remote side has closed the connection. In this case, if the
  273.     button panel is enabled, then the "Disconnect" button would be
  274.     changed to "Hide desktop" after the connection is lost.
  275.  
  276. --> "Defer screen updates" (no GUI equivalent)
  277.  
  278.     Value: time in milliseconds.
  279.     Default: "20".
  280.  
  281.     When updating the desktop contents after receiving an update from server,
  282.     schedule repaint within the specified number of milliseconds. Small delay
  283.     helps to coalesce several small updates into one drawing operation,
  284.     improving CPU usage. Set this parameter to 0 to disable deferred updates.
  285.  
  286. --> "Defer cursor updates" (no GUI equivalent)
  287.  
  288.     Value: time in milliseconds.
  289.     Default: "10".
  290.  
  291.     When updating the desktop after moving the mouse, schedule repaint within
  292.     the specified number of milliseconds. This setting makes sense only when
  293.     "Cursor shape updates" parameter is set to "Enable". Small delay helps to
  294.     coalesce several small updates into one drawing operation, improving CPU
  295.     usage. Set this parameter to 0 to disable deferred cursor updates.
  296.  
  297. --> "Defer update requests" (no GUI equivalent)
  298.  
  299.     Value: time in milliseconds.
  300.     Default: "50".
  301.  
  302.     After processing an update received from server, wait for the specified
  303.     number of milliseconds before requesting next screen update. Such delay
  304.     will end immediately on every mouse or keyboard event if not in the "view
  305.     only" mode. Small delay helps the server to coalesce several small
  306.     updates into one framebuffer update, improving both bandwidth and CPU
  307.     usage. Increasing the parameter value does not affect responsiveness on
  308.     mouse and keyboard events, but causes delays in updating the screen when
  309.     there is no mouse and keyboard activity on the client side.
  310.  
  311. --> "SocketFactory" (no GUI equivalent)
  312.  
  313.     Value: name of the class.
  314.     Default: none.
  315.  
  316.     This option provides the way to define an alternate I/O implementation.
  317.     The dynamically referenced class must implement a SocketFactory
  318.     interface, and create a Socket, as configured by this parameter. See the
  319.     source in the SocketFactory.class.
  320.  
  321.  
  322. RECORDING VNC SESSIONS
  323. ======================
  324.  
  325. Current version of the TightVNC Java viewer is able to record VNC (RFB)
  326. sessions in files for later playback. The data format in saved session files
  327. is compatible with the rfbproxy program written by Tim Waugh. Most important
  328. thing about session recording is that it's supported only if Java security
  329. manager allows access to local filesystem. Typically, it would not work for
  330. unsigned applets. To use this feature, either use TightVNC Java viewer as a
  331. standalone application (Java Runtime Environment or Java Development Kit
  332. should be installed), or as a signed applet. The code checks if it's possible
  333. to support session recording, and if everything's fine, the new "Record"
  334. button should appear in the button panel. Pressing this button opens new
  335. window which controls session recording. The GUI is pretty self-explained.
  336.  
  337. Other important facts about session recording:
  338.  
  339. --> All sessions are recorded in the 24-bit color format. If you use
  340.     restricted colors (8-bit format), it will be temporarly switched to
  341.     24-bit mode during session recording.
  342.  
  343. --> All sessions are recorded with cursor shape updates turned off. This is
  344.     necessary to represent remote cursor movements in recorded sessions.
  345.  
  346. --> Closing and re-opening the recording control window does not affect the
  347.     recording. It's not necessary to keep that window open during recording a
  348.     session.
  349.  
  350. --> Avoid using Zlib encoding when recording sessions. It's ok if you started
  351.     recording BEFORE the connection to the VNC server has been established,
  352.     but if you started recording during an active session, all Zlib sessions
  353.     will be saved Raw-encoded (that is, without compression at all). Zlib
  354.     decoding depends on the pixel data received earlier, thus saving the data
  355.     received from the server at an arbitrary moment is not sufficient to
  356.     decompress it correctly. And there is no way to say Zlib decoder to reset
  357.     decompressor's state -- that's a limitation of the Zlib encoder. The
  358.     viewer could re-compress raw pixel data again before saving Zlib-encoded
  359.     sessions, but unfortunately Java API does not allow to flush zlib data
  360.     streams making it impossible to save Zlib-encoded RFB pixel data without
  361.     using native code.
  362.  
  363. --> Usually, Tight encoding is the most suitable one for session recording,
  364.     but some of the issues described above for the Zlib encoding affect the
  365.     Tight encoding as well. Unlike Zlib sessions, Tight-encoded sessions are
  366.     always saved Tight-encoded, but the viewer has to re-compress parts of
  367.     data to synchronize encoder's and decoder's zlib streams. And, due to
  368.     Java zlib API limitations, zlib streams' states have to be reset on each
  369.     compressed rectangle, causing compression ratios to be lower than in the
  370.     original VNC session. If you want to achieve the best possible
  371.     performance, turn recording on BEFORE connecting to the VNC server,
  372.     otherwise CPU usage and compression ratios may be notably less efficient.
  373.  
  374.  
  375. HINTS
  376. =====
  377.  
  378. --> To refresh remote desktop in the view-only mode, press "r" or "R"
  379.     on the keyboard.
  380.  
  381.  
  382. ACKNOWLEDGEMENTS
  383. ================
  384.  
  385. This distribution contains Java DES software by Dave Zimmerman
  386. <dzimm@widget.com> and Jef Poskanzer <jef@acme.com>.  This is:
  387.  
  388.     Copyright (c) 1996 Widget Workshop, Inc. All Rights Reserved.
  389.  
  390.     Permission to use, copy, modify, and distribute this software and its
  391.     documentation for NON-COMMERCIAL or COMMERCIAL purposes and without fee
  392.     is hereby granted, provided that this copyright notice is kept intact.
  393.     
  394.     WIDGET WORKSHOP MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE
  395.     SUITABILITY OF THE SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT
  396.     NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
  397.     PARTICULAR PURPOSE, OR NON-INFRINGEMENT. WIDGET WORKSHOP SHALL NOT BE
  398.     LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING,
  399.     MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES.
  400.     
  401.     THIS SOFTWARE IS NOT DESIGNED OR INTENDED FOR USE OR RESALE AS ON-LINE
  402.     CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE
  403.     PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT
  404.     NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE
  405.     SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF THE
  406.     SOFTWARE COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE
  407.     PHYSICAL OR ENVIRONMENTAL DAMAGE ("HIGH RISK ACTIVITIES").  WIDGET
  408.     WORKSHOP SPECIFICALLY DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY OF
  409.     FITNESS FOR HIGH RISK ACTIVITIES.
  410.  
  411.     Copyright (C) 1996 by Jef Poskanzer <jef@acme.com>.  All rights
  412.     reserved.
  413.  
  414.     Redistribution and use in source and binary forms, with or without
  415.     modification, are permitted provided that the following conditions
  416.     are met:
  417.     1. Redistributions of source code must retain the above copyright
  418.        notice, this list of conditions and the following disclaimer.
  419.     2. Redistributions in binary form must reproduce the above copyright
  420.        notice, this list of conditions and the following disclaimer in the
  421.        documentation and/or other materials provided with the distribution.
  422.  
  423.     THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
  424.     ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  425.     IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  426.     PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS
  427.     BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
  428.     CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  429.     SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
  430.     BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
  431.     WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
  432.     OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
  433.     ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  434.  
  435.     Visit the ACME Labs Java page for up-to-date versions of this and other
  436.     fine Java utilities: http://www.acme.com/java/
  437.